• Reporting Problems
• MacTCP Q & A
• Domain Name Server Errors
• MacPPP Q & A
• InterSLIP Q & A
• Book 'Em, Danno

If you went through the various steps in the previous chapters to configure MacTCP and either InterSLIP or MacPPP and everything works, congratulations! Skip this chapter entirely, since it can get a bit technical in places and if everything works, there's no need to dwell on what might not work. Most people don't have much trouble, but there are some pitfalls to avoid and some tricks and tips I've learned since the first edition of this book. I'd like to share some of the problems and solutions with you here, and although I hope you don't need to read this section, if you do, I hope it helps. I've formatted the section along the lines of an Internet FAQ, or Frequently Asked Question, list. Within each section, I've tried to organize the question and answers roughly as you might experience them -- for example, there's no point in putting suggestions about improving performance before suggestions about how to get around a modem problem and connect in the first place.

Before I even begin to talk about what might go wrong, I want to say a few words about how you can best go about isolating problems and then reporting them on the nets or to tech support. If you ask for help on comp.sys.mac.comm by posting a note that says something like, "I'm connecting to the nets via SLIP and it doesn't work. What am I doing wrong?" you won't get any helpful responses. You probably won't get any responses at all, helpful or not, since people will have no clue what your problem is other than the fact that you don't know how to ask for help. If you follow the steps that I suggest when working through any problem, not only problems with MacTCP, MacPPP, or InterSLIP, you'll be better off.

When you've determined that you have a problem, do the following: Start over completely from scratch, removing from the System Folder all files related to MacTCP and MacPPP or InterSLIP, including preferences files.

Note: One quick way to find all these files for quick removal is to use the Find command in the Finder's File menu to search for "TCP" and either "PPP" or "InterSLIP." I recommend not actually deleting these files until you're up and running again, just in case, but that's why Apple created a persistent Trash.

After you've removed the old files, carefully follow each step in the instructions, noting anything that doesn't seem to mesh between your setup and what the instructions say. If you deviate from the instructions, note that, too. In many cases, following this procedure will either solve the problem or reveal where it lies. Taking something apart and putting it back together often fixes problems for no apparent reason. Don't think of this process as an unpleasant chore, because then you're likely to become careless and miss an important clue. Troubleshooting can be a lot of fun, since you learn a lot more about the topic at hand, and you get to solve a real-life mystery in which no one dies.

Unfortunately, because we're all amateur sleuths, we're not always able to find the solution to a problem and must consult others who are more knowledgeable or who have a different way of looking at the problem. If you are having trouble with a commercial program, the first experts to turn to should be the technical support staff at the company that produced your program. I've heard good things about most of the technical support staffs of companies that make Internet applications, although quality tech support is never guaranteed.

When dealing with telephone tech support people, keep in mind that they probably know a lot more about the program in question than you do, they answer a huge number of calls every day, and the job has a high burnout rate because it's so stressful. You're most likely to get the best help if you're polite and cooperate with what they ask you to do. If you call and announce that you're a power user and why doesn't this stupid program work anyway, you're unlikely to get decent help. If, on the other hand, you call, say that you're having troubles, and give the information the tech support person asks for, she can do a much better job. It never pays to alienate the person whom you're asking for help -- whatever is wrong is almost certainly not her fault.

If you are using a freeware or shareware application, it usually says whether or not the author is willing to help via direct email. One way or another, though, there are several places where you can ask for help from other users, many of whom are true experts. Also, the developers of many of the freeware and shareware utilities tend to hang out in these same places and help their users, even if they prefer not to be continually slammed by personal email. The best place to ask for help with Internet stuff is on the Usenet newsgroup comp.sys.mac.comm. There also are many knowledgeable people who hang out in the Apple Internet Users mailing list, which you can subscribe to by sending email to listproc@abs.apple.com with the command subscribe apple-internet-users Your Name in the body of the message. If you can post to a newsgroup, there are often newsgroups specific to your provider where local folks hang out and answer questions, like the halcyon.slip group at Northwest Nexus.

Note: If you don't read a newsgroup regularly, you should explicitly ask for replies via email so you don't miss any replies.

No matter what, if you want any of these people to help you, you must help them first by sending a complete report. In that report, you should include the following:

• List exactly what it is that you're trying to accomplish. This should be specific, since telling someone that you want to read Usenet news with NewsWatcher isn't salient to the problem of not being able to get InterSLIP to connect. Take each goal a step at a time.

• Mention the fact that you have carefully followed the directions. This fact tells people that (a) you're not a complete idiot and can read, (b) that you have gone through a certain set of procedures already, and (c) it tells them that you are capable of following any suggestions they make. If you haven't followed the directions carefully, don't bother posting until you do so.

• List the salient facts of your software and hardware setup. Include things such as what Mac you have, what modem you use, what version of the System software you're running, and any weird stuff that you can't eliminate from the testing (such as, for example, an Outbound user who had additional software from Outbound that was necessary for his machine to boot properly). Unless asked, don't bother listing out every extension and control panel on your hard disk. You should have already eliminated them in the process of testing by removing everything but MacTCP and either InterSLIP or PPP and Config PPP from your Extensions and Control Panels folders. Also, an unusually long report will turn many people off.

• Talk a bit about what you have already tried, whether or not it worked, and whether you noticed anything strange happening at any time during the process. If you encounter error dialogs at any time, report exactly what they say.

• Be nice. The last thing you want to do is insult an expert's favorite program, since they're less likely to help you at that point. When you're in trouble, it doesn't help to alienate anyone.

Before anything else, let me emphasize that you may need to reinstall a clean copy of MacTCP at various times to solve problems. Thus, you must keep a clean copy that you have never opened on a locked floppy. The copy that comes on the disk with this book qualifies as a clean copy of MacTCP.

Note: At some point you may want to set aside a clean, unused copy of MacTCP to facilitate reinstallations. To do so, move your existing copies of MacTCP and MacTCP Prep to the desktop, restart with extensions off, run the ISKM Installer and install just a new copy of MacTCP.When forced to restart, again keep the extensions off. This ensures that you have a clean copy of MacTCP in your Control Panels folder. Put that copy of MacTCP on a floppy as a backup. Then replace your old MacTCP and MacTCP Prep files and restart to return to your previous state.

Also, let me recommend that if you have FTP access, you get a copy of Peter Lewis's free MacTCP Watcher. It includes another document on troubleshooting MacTCP connections, written by Eric Behr. It's in:

ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/

Anyway, on to the questions and answers about MacTCP!

Q: I don't see an icon for InterSLIP or PPP in my MacTCP control panel.

A: Install InterSLIP or PPP in your Extensions folder, and try again.

A: Make sure that you select InterSLIP or PPP and not LocalTalk in the MacTCP control panel.

A: Ignore it unless you're on a subnet, which means you'll have a network administrator who can tell you what to do there.

A: No. Only enter a number there if you use a Manually-addressed account.

A: Your gateway address is determined by your server when you use Server addressing, which is why you can't type in there. InterSLIP fills it in for MacTCP, but it makes no real difference.

However, one reader found that in using VersaTerm SLIP, the first time you log in you must enter a Gateway address and your IP address into VersaTerm SLIP, via either the fields in the upper right of the configuration window or a small pop-up menu in VersaTerm AdminSLIP's terminal window. With Northwest Nexus, the Gateway address in this case is the first of the two IP numbers that the machine provides after you enter your login name and password, something like 198.137.231.150. Your IP address for that session is the second of the two numbers. Other providers may be similar.

A: MacTCP creates them when you restart, to store various settings and preferences. You can throw them out at any time with impunity, since MacTCP recreates them with the same settings when you restart. Note that you must restart after throwing them out since MacTCP applications require MacTCP DNR to work properly.

If you reinstall MacTCP without throwing out these files, MacTCP retains the settings it had before you reinstalled. This can be useful for moving copies of MacTCP around, but they also tend to retain any corruption.

A: I would completely reinstall MacTCP (throwing out MacTCP DNR and MacTCP Prep as well) and reconfigure to be safe, but I don't think you should worry too much. Anti-virus software like SAM can sometimes gets persnickety about MacTCP creating the MacTCP DNR file, and I could see that perhaps causing the problem.

In fact, I hear that if the MacTCP DNR files becomes corrupted, some anti-virus software, such as Gatekeeper, could possibly prevent MacTCP from updating it, which is a bad thing. If you use sensitive anti-virus software that tries to prevent unknown actions (Disinfectant is fine), to be very sure it isn't causing problems, turn it off, delete MacTCP, MacTCP DNR, and MacTCP Prep, reinstall a clean copy of MacTCP, restart, turn the anti-virus software back on, and restart again.

A: That's really weird, but one reader reported a reproducible conflict with a control panel from Apple called CPU Energy Saver. Try removing it and restarting. MacTCP should create a new MacTCP DNR file on restart if it's not present.

A: First, try opening MacTCP, changing something and then closing it. That should force the creation of a MacTCP Prep file in the Preferences folder. If that doesn't work, restart without extensions, particularly anti-virus programs, and try reconfiguring MacTCP again.

A: Possibly. First, connect again to see if Fetch works. If it does, you're fine. If it doesn't, throw out the MacTCP DNR file and restart. Try Fetch again. If it still doesn't work, completely reinstall MacTCP from scratch. This isn't usually necessary, luckily.

After a truly nasty crash, you may find it necessary to reinstall InterSLIP or MacPPP as well. If you use InterSLIP, remove your modem configuration file from the InterSLIP folder before reinstalling InterSLIP, since it's worth trying with your old configuration file before you toast it as well.

A: Yes and no. I seldom do it, but frankly, if anything goes wrong, reinstalling MacTCP is worth trying. Make sure to throw out MacTCP DNR and MacTCP Prep, too, since they can harbor the corruption that caused MacTCP to have problems in the first place. Always keep a copy of MacTCP on a locked floppy disk, to facilitate reinstalling.

A: Sure, why not? I personally haven't seen any problems in 2.0.2 or 2.0.4 that were fixed in 2.0.6, but others have, and it's a free update that's stored on:

ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/mactcp-206-updt.hqx

Besides, MacTCP 2.0.6 is on the disk that comes with this book, so you can install it from there if you want, first removing the old MacTCP, MacTCP DNR, and MacTCP Prep.

A: The MacTCP updater only works on a clean copy of MacTCP that has never been opened before. Get a new copy from your master disk, update it, and the updater will work fine. Then, keep a clean copy of 2.0.6 on a locked floppy somewhere for use when reinstalling.

I've noticed many people running into a problem where SLIP or PPP (any implementation) connects properly, but trouble arises with the domain name server when they attempt to run any of the other MacTCP programs. Sometimes they crash or hang, but the behavior is usually completely reproducible (although we have seen the occasional exception, where it will work fine once after reinstalling MacTCP but fail on subsequent connections). This problem occurs primarily in Server-addressed situations, but I've heard sporadic reports from people using Manually-addressed accounts.

I haven't absolutely solved this problem yet, I'm sorry to say, but here are some things to try. I find that the easiest way to test this situation is with Peter Lewis's free MacTCP Watcher, which shows an IP number but no Mac name in this instance. It also complains about a "No answer error" or a "Cache fault error" when it is unable to find the domain name server. If you use Fetch, you can tell quickly that you are seeing the problem if when you connect, the dog cursor is frozen. If the dog cursor runs, you're generally better off. If the cursor is frozen, immediately hit command-period to try canceling the connection before Fetch hangs. NCSA Telnet can prove useful as well, since in some cases you may be able to telnet to a machine by using its IP number, but using the domain name fails. This indicates that the connection works, but that there is a problem resolving domain names.

Note that the problem is generally not with your account. Each time someone has had this problem and asked me to check their account, it has worked fine if they did indeed have a SLIP or PPP account, although trying to connect via SLIP or PPP to a shell account can cause the problem. That said, here are some things to try, in this order:

• Disconnect, reboot, and reconnect. Sometimes that's all it takes.

• Throw out your MacTCP DNR file, and restart. Sometimes this file becomes corrupted, and MacTCP will create a new one on restart if necessary.

• Check your domain name server configuration in MacTCP carefully to make sure you typed the correct IP numbers. I've made this mistake before.

• If you are using a Manually-addressed account, make sure you have typed the correct number into the Gateway address box in MacTCP's configuration dialog. Only your provider can tell you what your Gateway address is -- you cannot guess it.

• If you use InterSLIP, make sure you're using the appropriate gateway script for your provider. Without this, your Mac may be unable to get an IP number properly. A number of people try to use the Simple UNIX/Telebit script that's built into InterSLIP when they should use a custom gateway script. The Simple UNIX/Telebit script simply won't work with a Server-addressed account like those that Northwest Nexus provides. This is because gateway scripts for providers like Northwest Nexus are designed to find your IP number from the login message each time you login. If you use the Simple UNIX/Telebit script instead, it completes successfully after sending your userid and password, and ignores the IP address that appears next.

• Login with a terminal emulator just to make sure your account is set up for SLIP or PPP. If after providing your user name and password and send any necessary commands to start SLIP or PPP (ask your provider if any are necessary), you don't see garbage or something like "SL/IP session beginning..." and you get to a Unix prompt, then your account has not been set up for SLIP or PPP. Ask your provider to fix it. This is a common mistake for overworked providers.

• If for some reason you are using InterSLIP 1.0fc3, use version 1.0.1 (or later) since that version solved various problems like this. It's on the ISKM disk.

• Reinstall MacTCP from scratch. Hey, it's easy, but you'd be surprised how much it helps.

• Make sure your domain name server information in the MacTCP configuration dialog looks something like this (it will be different for your domain if you don't use Northwest Nexus):

  halcyon.com      198.137.231.1
                   198.137.231.1
                   192.135.191.1
  

• Try turning off Virtual Memory, if you're using it, or disabling RAM Doubler, if you're using that. One person reported success without Virtual Memory enabled.

• Ask your provider if other people are experiencing this problem as well, since it may in fact be related to an overloaded domain name server. They may be able to use a different machine for DNS services and solve the problem that way.

• Try using a different telephone cord to the modem. In one case, a slightly bad telephone cord caused some line noise that messed up InterSLIP in such a way as to cause this error.

• Okay, here's a major realization we've made (thanks to Michael Tardiff for tremendous help in figuring this out). If nothing so far has worked, check to make absolutely sure that you are using hardware handshaking with your modem, and more importantly, make sure XON/XOFF is turned off. It seems that if XON/XOFF is turned on, the SLIP or PPP program may appear to log in properly, but will fail to find the Gateway address properly.

  Server-addressed accounts determine the Gateway address at connect time, which is why you cannot type it into MacTCP. Nonetheless, if, in InterSLIP (and MacPPP, we think) you don't properly use hardware handshaking, then some sort of initial negotiation that determines the Gateway address fails. When that happens, a necessary line of communication with the host is broken. The upshot of this is that MacTCP Watcher will find no Mac name for your Mac. That Mac name should be supplied by reverse name mapping, but it seems that if that initial negotiation after the login process fails, the Mac receives no Mac name from the host via the gateway. Using exactly the same settings otherwise, we showed that merely toggling a modem setting that turned hardware handshaking on and off could make the difference between a successful connection and a failed one.

• Make sure that your modem cable is indeed a hardware handshaking cable. Most high-speed modems purchased in "Macintosh kits" within the last few years include proper hardware handshaking cables, but if you bought a modem without a cable, or you bought a new cable separately from a computer store, your cable may not be a proper hardware handshaking cable. You may need to call your modem vendor to confirm this. Modern hardware handshaking cables should have the pinouts shown in Table 20.1. You can test this if you have the proper electronic testing equipment, or you can construct an electric testing device that turns on a light or makes a noise when a circuit is closed by touching leads to the proper pins (I once used an empty battery-powered squirt gun to indicate when a circuit was completed).

      Table 20.1: Hardware Handshaking Cable Pin-out
  
  Mac Function      RS-232 Function     Mac Pin     DB-25 Pin
  
  RxD (receive)     Receive Data        5           3
  TxD (transmit)    Transmit Data       3           2
  Ground            Ground              4 & 8       7
  HSKi              CTS                 2           5
  HSKo              RTS & DTR           1           4 & 20
  GPi               CD                  7           8
  

• If you do not have a hardware handshaking cable, you can purchase them from numerous sources, but insist on a hardware handshaking cable, not just a modem cable. Jump up and down, yell, and scream, if necessary, but the two terms are not necessarily interchangeable. I've ordered high-quality, properly wired cables for about $15 from the Celestin Company, 800/835-5514, 360/385-3767, 360/385-3586 (fax), celestin@olympus.net

• Once you determine that your modem cable is indeed a hardware handshaking cable, next ensure that hardware handshaking is turned on in your SLIP or PPP program. You may see a checkbox labeled Hardware Handshaking, as in InterSLIP, or a pop-up menu listing choices such as XON/XOFF, CTS, RTS, and CTS/RTS. Choose CTS or CTS/RTS for hardware handshaking. There are other terms for the RS-232 functions that some programs use -- if you're confused, ask the program's tech support folks. Hardware handshaking is usually relatively easy to check and set.

• Unfortunately, simply turning on hardware handshaking in your SLIP or PPP program may not be sufficient. It seems that some modems set XON/XOFF, or software handshaking, in their default settings. Thus, when you initialize the modem with the factory default initialization string, you actually turn software handshaking back on. This is bad. I ran into this with a Telebit QBlazer, which defaults to software handshaking with the setting S58=3. By changing that to S58=2 in the initialization string, the domain name server errors disappeared immediately because InterSLIP could then complete the negotiation for the Gateway address and the reverse name mapping that goes on right after the login process.

  VersaTerm AdminSLIP may not always suffer from the same problem as InterSLIP. Merely setting hardware handshaking in the configuration window enabled the QBlazer to work, whereas checking the hardware handshaking box in InterSLIP had made no difference. Nonetheless, consult the fine print in your modem's manual for the settings to ensure that hardware handshaking is enabled. Look for settings called DTE Flow Control. In Telebit modems, those settings are controlled by the S58 register, although other modems undoubtedly differ.

• Try using another modem. This worked for one user who switched from a Zoom 2400 bps modem to a QuickTel v.32bis modem. This may well have been related to the hardware handshaking issue.

• Try booting from another hard disk, if you have one.

• Try installing MacTCP and the other software on another Macintosh, if you have one.

• Try rebuilding your desktop. I have no idea why this would make a difference, but it's worth a try. You can rebuild your desktop by holding down the Command and Option keys during startup until the Macintosh asks you if you want to rebuild the desktop.

• Try zapping your PRAM (Parameter RAM -- it stores various low level settings). I have no idea whether this makes any difference, but anything is worth a try at this point. To zap your PRAM in System 7, hold down [Command]-Option-P-R while restarting the Mac. You will lose certain settings such as the time and the mouse speed setting, but you can reset those later.

• Try reinstalling your System. First, make sure you have a full set of System disks, since you must disable the System on the hard drive before installing, to ensure a completely clean install. Then, drag your System file to your desktop and restart with the Install disk. Install the System and then restart with your hard disk again. Throw out the System file sitting on your desktop, completely reinstall MacTCP (throwing out MacTCP DNR and MacTCP Prep), and MacPPP (throw out PPP Preferences along with the PPP extension and Config PPP) or InterSLIP (throw out the entire InterSLIP Folder, the InterSLIP extension, and InterSLIP Setup). If any updates from Apple exist for the version of the System you use, reinstall them as well. Then, try again. At least one MacPPP user solved the problem this way.

• Consider switching to the commercial VersaTerm SLIP, MacSLIP, or InterPPP. This may work because of differences in the ways the programs handle Gateway addresses for Server-addressed accounts and the way they specify hardware handshaking for different modems.

• Try a different provider.

• If none of these suggestions help, I don't know what to say, except that some problems are never solved. Otherwise, we'd have world peace.

Although its interface can seem a bit confusing, MacPPP is actually quite easy to configure and use. But, there are still some questions.

Q: I want to switch from InterSLIP to MacPPP. What should I watch out for?

A: First, you need a new account. Second, I don't recommend leaving the InterSLIP extension installed at the same time as the PPP extension. Third, reinstall MacTCP from scratch before trying to connect with MacPPP. Frankly, if everything works fine with InterSLIP, I don't recommend bothering to switch.

A: Select the Modem port. Non-bus internal modems in some PowerBooks (typically the 100-series) connect to an internal modem port connector. Bus modems like the Apple Express Modem and the Global Village PowerPort/Mercury for the PowerBook 500-series and the PowerBook Duo should be set to Internal Modem.

A: In the PowerBook Setup control panel, there's a setting on how the modem should be treated. If it's set to Compatible, your Printer-Modem port won't appear in the Port Name menu. Set the PowerBook Setup control panel's Modem setting to Normal and all will be well.

A: It's been suggested that if you installed MacPPP with SAM active, and used the "allow" feature in SAM, that MacPPP and possibly MacTCP would be corrupted. The fix is to turn SAM off and reinstall both MacTCP and MacPPP from scratch.

A: The first, and most likely possibility is that you have not selected the PPP icon in the MacTCP control panel. Make sure it's selected (try selecting another icon in MacTCP then reselect PPP), and try again.

There are some known conflicts that might cause this. One possible conflict might be with an older version of the shareware SpeedyFinder, although the most recent versions solve this. Also, the elderly screensaver called Moire has been implicated in this problem as well. Finally, many Performas came with 2400 bps Global Village TelePort/Bronze modems, and if you upgrade to a faster modem, you should move the Global Village Toolbox file out of the Extensions folder and the GV TelePort Bronze file out of the Control Panels folder before trying again. And of course, if you have the SLIP extension from VersaTerm SLIP, InterSLIP, or MacSLIP installed, that may cause the problem as well.

Also, be very wary of any fax or remote control software that may have taken over the modem. Even if it doesn't conflict directly with MacTCP or MacPPP, the fax software may leave the modem in such a state that MacPPP is unable to access it.

A: Reinstall MacTCP from scratch, making sure to delete MacTCP DNR and MacTCP Prep. This one once threw me for an hour.

A: Okay, one last possibility. Try reinstalling your System from scratch. Reinstalling the System seemed to help a number of users (mostly using Macintosh Performas) with this problem. First, make sure you have a full set of System disks, since you must disable the System on the hard drive before installing, to ensure a completely clean install. Then, drag your System file to your desktop, and restart with the Install disk. Install a new System, and then restart with your hard disk again. If any updates from Apple exist for the version of the System you use, reinstall them as well. Throw out the System file sitting on your desktop, then completely reinstall MacTCP (throwing out MacTCP DNR and MacTCP Prep as well) and MacPPP (throw out the PPP extension and the Config PPP control panel), and try again.

A: This timeout is independent of the modem initialization string, since MacPPP isn't even getting that far. The problem is probably related to the flow control or port speed settings. Try different settings, and make sure you don't select 14,400 or 28,800 for the port speed, since some modems can't handle those as port speeds.

Also, it's possible that you have a bad modem cable, although you would probably have noticed that before.

A: Ah, that's different. Larry Blunk mentioned a problem with the Supra and perhaps some other internal PowerBook modems. It seems that they are normally in a low-power state and can take a few seconds to warm up when MacPPP opens the serial driver and tries to dial out. Because the modem is warming up, it ignores the first initialization string that MacPPP sends, and MacPPP doesn't currently try again. The workarounds include using the terminal window or trying to script the modem initialization string in the Connect Script dialog. Larry says he's fixed this in an as-yet-unreleased version of MacPPP.

A: In some cases, the terminal window doesn't display the characters you type (this may be related to local echo settings in the modem initialization string) until you press the Return key. Typing blind is a pain, but you shouldn't have to use the terminal window much.

A: Some modems don't work well at speeds over 19,200 with their default configurations. You may need to twiddle with the modem initialization string to get them to work. Don't worry about it too much though, since 19,200 bps is fast enough for a 14,400 bps modem.

Also, activating the FAXstf 3.0 LineManager option, according to one reader, prevents MacPPP from working with the SupraFAXmodem v.32bis at speeds above 19,200. In general, distrust fax software.

A: You're confusing modem speed and port speed. The port speed setting in MacPPP should always be set faster than the modem speed to take advantage of modem compression capabilities. Some modems don't recognize 14,400 or 28,800 bps as valid port speeds and won't work at all.

A: One reader reported a problem like this. It seems that the remote system sent a "banner page" of all sorts of text after accepting the password, but before starting PPP. MacPPP saw the banner page and got confused, because it was expecting PPP code at that point. The solution is to send several \d delay tags after sending the password; that gives MacPPP some time to ignore the banner page before starting PPP.

A: The most likely reason is that something in the login chat script is wrong. You may have entered the wrong userid or password, or entered them incorrectly. It's also not uncommon for a provider to make a mistake in setting up an account such that it's not a PPP account, or perhaps such that it links to a different userid or password.

Also, see the previous question and answer, since sometimes the problem above doesn't result in a crash, but merely a Link Dead message.

Finally, some providers give different userids and passwords for dialing in than they do for email, say, or different userids and passwords for shell accounts versus PPP accounts. Double check to make sure you've using the correct ones.

A: Click on it. I'm not positive of the circumstances in which this dialog appears, but I always just click on Retry and eventually it connects.

A: This appears to be a problem exclusive to the PowerPort modems in the PowerBook 500-series. The problem lies in the Global Village software, and is actually only cosmetic, although it's easy to get impatient and assume it's not working. Check for a later version of the Global Village software in:

ftp://ftp.globalvillag.com/pub/software/

A: Click on the Hard Close button, rather than on the Soft Close button, to disconnect. The drawback to doing this is that you cannot use MacPPP's auto connect feature after this unless you restart. Also, set a short idle timeout in Config PPP so it hangs up relatively quickly if MacPPP does dial on its own.

Make sure you don't have any MacTCP-based applications or control panels (like Network Time) set to launch during startup. They'll force MacPPP to dial out every time.

A: First, if you have the port speed set to 57,600 bps, try setting it down to 38,400 bps or 19,200 bps, especially if you're using a slower Macintosh with a fast modem.

Second, I've seen this happen with MacPPP and with MacSLIP, but in both cases, I was able to solve the problem by turning off all unnecessary extensions and control panels. The hard part, then, was isolating which of them were actually causing the problem, and in some cases, more than one did. On my parents' LC II running MacSLIP, the APS PowerTools CD driver software turned out to be the culprit. On my PowerBook 100 (this was an embarrassing problem that haunted me for months), the problem was caused by PBTools 2.0, a PowerBook utility. Another user reported problems with SuperClock and the Spirit CD control panel. In general, I'd look for any control panel or extension that is in constant use, like a clock, a battery-monitoring utility, or a CD driver control panel (two others of which, the MindLink CD driver and the Apple CD driver, have been implicated in other performance problems as well).

A: No, but one reader who was experiencing this tracked it down to a conflict with SAM, the anti-virus program. If you're running SAM or any other anti-virus software, try removing it first. Then, if that doesn't work, try shutting off all unnecessary extensions and control panels and see if that makes a difference. If it does, work your way back up to a full set and see which file is the culprit. I personally use and recommend only Disinfectant for anti-virus purposes.

Since its introduction in 1993, InterSLIP has become popular for its combination of flexibility, utility, and price -- it's free. However, InterSLIP isn't always trouble-free. Following are some of the more common questions and answers relating to InterSLIP.

Q: I can't find InterSLIP Control on my disk.

A: You don't need InterSLIP Control if you use System 7. It is necessary only with System 6.

A: Two things to check here. Those files should be text files, so if they are any other type, they may not show up, since InterSLIP won't recognize them. If you simply save from Microsoft Word, for instance, those files will be of type WDBN and not of type TEXT. Use Save As and select the Text Only option that exists in most word processors. Second, if you copy those scripts in while InterSLIP is running, it won't recognize them until you quit and launch InterSLIP Setup again. You don't have to restart; simply quit and relaunch.

A: In my experience, InterSLIP's auto connect feature doesn't work very well. This may not be InterSLIP's fault, and it does work for some people, so if it does for you, great. If not, make a habit of connecting manually before you launch a MacTCP program such as Fetch. Since Eudora doesn't open MacTCP until you check for mail, you can use it without connecting InterSLIP first. One person said that he had solved his auto connect problems by adding a "pause 30" statement in his Gateway script just before it exits. This may help, although my Mac never even dials the phone before freezing on auto connect.

A: This points directly at an extension conflict with either InterSLIP or MacTCP. I would recommend pulling all unnecessary extensions and control panels out. Or, better yet, use an extension manager such as Apple's free Extension Manager, or the powerful (but commercial) Conflict Catcher from Casady & Greene, which can actually help in your testing process. Leave only MacTCP and InterSLIP, and try again. If the problem disappears, slowly replace the extensions and control panels that you use until the problem reappears, identifying the culprit in the process. We've seen problems possibly related to MacTOPS, DOS Mounter, SuperLaserSpool, and GlobalFax, and a two-way conflict with AutoRemounter and PSI FaxMonitor. In general, be very wary of any extensions that modify a network or a modem, including fax or remote control software. I'm also generally suspicious of anti-virus software. Even if these programs don't specifically conflict with InterSLIP or MacTCP, they may leave the modem in such a state that InterSLIP cannot dial out properly.

A: Try reinstalling MacTCP from scratch (throwing out MacTCP DNR and MacTCP Prep) and InterSLIP (throw out the entire InterSLIP Folder, the InterSLIP extension, and InterSLIP Setup), and reinstall from fresh copies. If you have custom scripts, there's no need to throw them out.

A: Shoot. The next thing to try is reinstalling your System. First, make sure you have a full set of System disks, since you must disable the System on the hard drive before installing, to ensure a completely clean install. Then, drag your System file to your desktop, and restart with the Install disk. Install a new System, and then restart with your hard disk again. If any updates from Apple exist for the version of the System you use, reinstall them as well. Throw out the System file sitting on your desktop, then completely reinstall MacTCP (throwing out MacTCP DNR and MacTCP Prep) and InterSLIP (throw out the entire InterSLIP Folder, the InterSLIP extension, and InterSLIP Setup), and try again.

A: Okay, I don't really know what's happening here. Try getting a PPP account and use MacPPP, or purchase VersaTerm SLIP or MacSLIP and see if they work any better. I wish I could give a better answer, but I can't.

A: You need a dialing script, which is similar to an ARA script. For starters, I recommend the Minimal Dialing Script I provide on the disk. It works with most modems if you enter the proper modem initialization string.

A: I've seen this happen a few times. I suspect the script is in some way incorrect -- perhaps the error correction and data compression have been turned on improperly. Try the Hayes-Compatible Modem script. If that doesn't work, try the Minimal Dialing Script on the disk. If that doesn't work, ask your modem company for a good ARA script that you can modify (in theory, an ARA script should work without modification, but is best when modified). If that fails, beg for help from others with the same modem on the nets, preferably in comp.sys.mac.comm or the Apple Internet Users mailing list (see the "Reporting Problems" section earlier in this chapter for subscription information).

A: The most likely reason is that something in the login chat script is wrong. You may have entered the wrong userid or password, or entered them incorrectly. It's also not uncommon for a provider to make a mistake in setting up an account such that it's not a SLIP account, or perhaps such that it links to a different userid or password.

Also, some providers give different userids and passwords for dialing in than they do for email, say, or different userids and passwords for shell accounts versus SLIP accounts. Double check to make sure you're using the ones.

Finally, use a terminal emulator to walk through the login process manually. Sometimes, the provider's system is experiencing a high load and doesn't respond to your gateway script quickly enough. If this might be the case, try increasing the numbers in the statements that serve as timeout values.

A: Some modems, the US Robotics Sportster and the Global Village TelePort/Gold in particular, sometimes have problems if you are using an incorrect modem initialization string. Check your string carefully.

Also, I've noticed that sometimes I'll see failed connections on my Northwest Nexus account. They range from receiving tons of data when InterSLIP says "Waiting for prompt," to nothing at all happening when InterSLIP says "Waiting for prompt," "Sending username," or "Sending password." I've even had InterSLIP report "Login incorrect" when I know full well it was fine. Just try again a few times, waiting a bit between tries, if you can. I suspect these problems are related to a bad modem, line noise, or some other situation out of your control, and in my experience they always go away after several tries.

Again, check to see if the timeout values in your gateway script might be too short. If the script times out before you get in on some occasions, it could cause this frustrating inconsistency.

Finally, some people have suggested renaming the Global Village extensions used by Global Village modems so they load after MacTCP. It's worth a try if you have one of those modems.

A: Try toggling your TCP Header Compression checkbox (also sometimes known as CSLIP). If that checkbox doesn't match the setting for your account, things will fail. Essentially what happens is that small tasks such as looking up a machine name succeed, but anything else fails.

A: It could be related to your modem init string's settings for flow control, so check that carefully. Make sure you're using the proper MTU size in InterSLIP. Also, try turning off all unnecessary extensions, using an extension manager or by simply dragging them from the Extensions and Control Panels folder to "Extensions (disabled)" and "Control Panels (disabled)" folders. As a last resort, try InterSLIP 1.0.2d2 (or later) if you're using 1.0.1.

If you use the Apple Express Modem or a GeoPort Telecom Adapter, also make sure to try the latest Express Modem software, available at this or another Apple FTP site:

ftp://mirror.info.apple.com/Apple.Support.Area/Apple.Software.Updates/US/Macintosh/Networking.and.Communications/Other.N&C.Software/

A: Delete your InterSLIP Prefs file. For some reason, possibly related to the location of the InterSLIP Setup window, this has happened on several machines we've seen.

A: First off, if you use a dialing script other than the built-in Hayes-Compatible Modem script, it usually will have an @hangup section. My Minimal Dialing Script has one, and will hang up the modem just fine if you use it instead of the Hayes-Compatible Modem script.

Some people recommend adding &D2 to the end of your modem initialization string. Doing so will hang up the modem if DTR goes low, which it does when you click the Disconnect button. Unfortunately, DTR can also go low if you have a fast modem and a slow Mac and the modem transfers more data than the Mac can handle at that point. Using a port speed of 38,400 bps or 57,600 bps with a 14,400 bps modem can exacerbate this problem. If you run into this problem, you'll see random hang-ups while downloading large files. If you do use &D2, you may be able to set an S-register (S25 in at least some modems) in the modem init string that lengthens the time DTR can be low before the modem realizes it, thus preventing the hangups. Only worry about this if you like reading modem manuals. Overall, the Minimal Dialing Script is a better solution.

It's been fun, I'm sure. We've tracked down and locked up tons of problems, and I hope that any culprit that's been harassing you is among them. Perhaps the most important thing to do when troubleshooting is to remain calm and proceed methodically. If you do that, you're well on your way to finding and eliminating the problem.

Actually, the real fun comes in the next few chapters, where I talk about all of the programs that rely on the connection that you've established with MacTCP and either MacPPP or InterSLIP.